Aren't those still used?

The design in the task description doesn't have that extra margin which would make the gaps uneven. Tereza agreed on 4px (.25 rem) for both gaps

Even so, I believe they're still being referred in the code

That was only needed previously when it was considered the leftmost and only element in that group. Now I add the gap from the parent component, so I removed the div entirely.

The props being passed seem inconsistent here - strings in one place and FormattedMessage for the other props. I wonder if all strings makes more sense here?

I think I need to pass the node here because I don't see how else I'll be able to bold the text just inside the Tooltip component.

You can consider intl.formatMessage as well

If we truly want to make this component generic, we should make these configurable.

The tooltip display is generally a part of another task - https://scratchfoundation.atlassian.net/browse/UEPR-522, so we don't need to handle it here. There are also more specific requirements that we need to implement, but I'd suggest leaving this as is for now and then finishing/updating the callout work as part of the other task.

Maybe rename these to side and align? I think it'd be easier for readers to understand which is which.
side - On which side of the anchor element should the prompt be displayed (top, bottom, left, right)
align - Where should the arrow be placed (left, center, right)

If we go with this approach, we'd also have to flip the logic for left and right for the secondary position. Right now, left indicates that most of the content is displayed on the left side of the button, but the arrow is displayed on the right side of the modal itself, which was not what I expected seeing this configuration.

I can also see arrowPosition as an alternative naming for the align prop

since secondaryPosition is more about where the entire modal is placed (instead of centrally) I'll rename it to align

Let's add these values to an enum, instead of hardcoding them

Can we:

• pass the positioning params (width, arrow sizes, ..) as a configuration object to the ConfirmationPrompt
• reuse this component for the delete confirmation prompt, since it already contains a less complex version of the logic used here

What I find slightly confusing about the current implementation is the following structure:

• PopupWithArrow is a generic component used by ConfirmationPrompt, DeleteConfirmationPrompt, and FeatureCallout.
• ConfirmationPrompt is also a generic component, but it's currently only used for the thumbnail confirmation prompt and not for the delete confirmation prompt.

I think what we actually need is a clearer separation of responsibilities:

• SetTooltipConfirmationPrompt should use ConfirmationPrompt and pass in specific content such as title (if needed), description, className, layout, etc.
• DeleteConfirmationPrompt should also use ConfirmationPrompt and provide its own specific content.
• ConfirmationPrompt should use PopupWithArrow, which handles alignment and positioning.
• FeatureCallout should use PopupWithArrow for alignment and positioning.
• PopupWithArrow should use ReactModal to leverage its built-in behavior for handling outside clicks, escape key presses, etc.

This structure would simplify the overall design and ensure that each component has a clear, single responsibility. We may still need to refine the naming to better reflect each component's purpose, but this is the general direction I think we should take.

I can also see arrowPosition as an alternative naming for the align prop

I agree - if we are updating this to be async, we should update all usages (so including the project-saver-hoc

Is this needed?

currently yes because of the earlier all: unset; on the button

I wonder if that's a sign not to use all:unset but rather change what actually needs to be changed? My concern is that we may unset some default button styles that we haven't though of testing. I don't have a strong preference though, that's just a thought.

Are you sure a negative gap is what you want? Or do you indeed want to reduce paddings / margins?

It is that way by design. I guess it's not terribly important whether we have it or not but I don't see a reason to diverge.

I think we should overall try to avoid negative gaps/margins. It could be something that was added unintentionally (e.g. sometimes Figma adds certain styles when you move components). I think we should either remove it if we don't need it or try to achieve the same UI another way if possible.

I see a lot of similarities between the tooltip and the confirmation modal - the calls to calculatePopupPosition, the layout config, the arrowHeight / width. Do you see potential in extracting a common component between the two?

Such behaviors seem like we are implementing parts of the standard <Modal behaviour. Is there any potential in using a modal component underneath?

Perhaps, but I believe that after bringing out the shared logic for PopupWithArrow, the component is simple enough.

+1, most of these useEffects will become redundant if we switch to a Modal.

I agree - if we are updating this to be async, we should update all usages (so including the project-saver-hoc

I wonder if that's a sign not to use all:unset but rather change what actually needs to be changed? My concern is that we may unset some default button styles that we haven't though of testing. I don't have a strong preference though, that's just a thought.

Hmm, onUpdateProjectThumbnail already accepts onSuccess, onError. Can we not pass the callbacks directly? Why do we need to await the promises?

Instead of using formatMessage inside a FormattedMessage, you can do something like what I've done in this PR. Basically that way you can simply add <b>...</b> in the message definition and that would bold it.

+1, most of these useEffects will become redundant if we switch to a Modal.